Referring to FIG. 1, an exemplary computer system 105 according to the conventional art is shown. As depicted in FIG. 1, the computer system 105 comprises a northbridge 110 chip set. A processor 115 is coupled to the northbridge 110 for processing addresses, data, and instructions. A computer-readable memory 120 (e.g. random access memory, and/or the like) for storing addresses, data and/or instructions is also coupled to the north bridge 110. The computer system 105 also includes various system and periphery devices 125-165 coupled to the northbridge 110. The north bridge 110 acts as a simple input/output hub for communicating addresses, data and instructions between the processor 115, computer-readable memory 120, and/or the various system and periphery devices 125-165.
Certain functionality, processes, steps, and/or benefits implemented by the computer system 105 are realized as a series of instructions (e.g. software program) that resides within the computer-readable memory 120 and are executed by the processor 115. Such instructions may also be read into the processor 115 from another computer-readable medium (e.g., 126, 131, 136, 137, 146, 165). The terms “computer-readable memory” and “computer-readable medium” as used herein refers to any medium that participates in providing instructions to the processor 115 for execution. Such a medium may take many forms, including, but not limited to, firmware, flash memory, random access memory, floppy disks, magnetic disk, CD-ROMs, DVDs, memory cards, transmission medium, and/or the like. Furthermore, various forms of computer-readable medium may be involved in carrying one or more sequences of one or more instructions to the processor 115 for execution.
When the computer is first powered on, the processor executes a basic input/output system (BIOS) routine. The BIOS is stored in a system BIOS 165 (e.g. computer-readable medium such firmware, flash memory, and/or the like). The BIOS is a set of essential software routines that test hardware at startup, starts the operating system, and supports the transfer of data among system and periphery devices 110-165. The BIOS includes a separate bus-specific program called a bus enumerator, to determine what devices exist and what configuration requirements each device has. The bus enumerator however, does not enable the devices.
The BIOS passes a list of all the devices that the computer has to work with, as determined by the bus enumerator, when it boots the operating system. The operating system loads one or more applicable drivers from a mass storage device type of computer-readable memory (e.g., 131, 136, 137, 146) into the system type computer-readable memory 120. The particular drivers loaded are based upon a plurality of mappings contained in a registry (also known as a system registry, initialization file, configuration file, or the like). As each applicable driver is loaded, the operating system causes execution of each driver's initialization code, thereby enabling the device.
Referring now to FIGS. 2A-2B, a flow diagram of a method of initializing a plurality of hardware devices according to the conventional art is shown. As depicted in FIGS. 2A-2B, the bus enumerator routine sends a query to each device on a respective bus, at step 205. The query causes each device present to return configuration data, at step 210. The configuration data is contained in a plurality of configuration registers of each attached device. The configuration data comprises a device identifier and is utilized to map the device to a corresponding driver that provides for operation of the device.
The bus enumerator routine stores the received configuration data in memory, at step 215. Thereafter, the operating system is booted. A memory location pointer, to the configuration data, is passed to the operating system at start up, at step 220. The operating system then utilizes a registry (e.g., registry, system registry, initialization file, configuration file, or the like) (hereinafter referred to as a registry) to map each device to a driver, at step 225. More specifically, for each device configuration data stored in memory, the operating system parses the registry to determine the device driver associated with the particular device. The device is specified by a device identifier, which uniquely identifies the physical device (e.g., product E from manufacturer B).
If the registry contains a mapping of the device driver to the particular device specified by the set of configuration data, the driver is loaded into the operating system, at step 230. As each driver is loaded, the operating system calls the drivers initialization code entry point and the driver completes the device-specific setup of the device.
However, if the registry does not contain a mapping between a particular set of configuration data and a device driver, the operating system will initiate an installation routine at step 240. The installation routing typically prompts the user to install a device driver, which is capable of enabling the particular device. Along with loading the device driver, the driver install routine also changes the registry to contain a mapping of the device to the applicable driver. Typically, the driver installation routine then causes the computer system to reboot to complete the install process. Thus, the startup process begins again at step 205
Referring now to FIG. 3, an exemplary configuration data structure and registry according to the conventional art is shown. As depicted in FIG. 3, previous installation of various drivers has resulted in the registry containing mappings between device identifiers AA, BA, BB, BC, CA, CB and drivers A01, B01, B03, B03, C01, CO2 respectively. Upon the next startup of the computer system, an enumerator routine finds device AA, BE, and DA.
Device AA has previously been installed in the system. Device AA contains a value of AA in its device identifier register. The registry contains a mapping between device identifier AA and driver A01. Therefore, the operating system will load driver A01 to control device AA.
Device BE has just been installed in place of an older version of the device (e.g., BC). Device BE contains a value of BE in its device identifier register. The registry contains mappings for the prior versions BA, BB, and BC of the device. Even if driver B03, which is present in the computer system, provides for control of device BE (e.g., backward compatible with driver B03), the operating system will initiate a driver installation routine. The driver install is required because there is no current mapping between the particular device identifier and any applicable driver.
Similarly, device DA has also just been installed in the computer system. Device DA contains a value of DA in its device identifier register. The registry, however, does not contain a mapping for device identifier DA. Thus, the operation system will initiate a driver installation routine.
In the conventional art, a unified driver can typically control the operation of number of devices, thereby providing backward and some forward compatibility. The prior generation of such a driver, however, only enables the functions in a new device that are common to the older generation devices of the same type. New functions that were not known at the time the driver was created will be unavailable. Furthermore, if the drivers are backward and forward compatible, a device can be controlled by any of such drivers.
Thus, a device can be associated with any number of related unified device drivers that supports sufficient operational functionality. However, the device configuration data does not currently provide a means for identifying unified drivers that are already loaded into the computer system and are capable of controlling the device. As a result, even if the computer system contains a unified driver (e.g., driver B03) that can control the device (e.g., device BE), the user must execute a set up routine to change the registry in order to relate the device identifier of such device to an existing unified driver.